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ABSTRACT 



The disclosure includes a computational system imple- 
mented with respect to a novel computational architecture 
for operating an externally-defined data based on client- 
defined rules. In one of the implementations, the architecture 
is utilized in a billing and customer service program. The 
architecture includes a engine unit which includes a number 
of processing modules which internally operate on generic 
data units that are independent of the particular application. 
A metadata engine receives externally-defined data and 
relates the externally-defined data and the relates the 
externally-defined data to the generic data units for use for 
the engine unit. A rules-based engine provides to the engine 
unit information related to the client defined rules. In this 
manner, the engine unit can be reused in a large part in a 
variety of different environments. 

35 Claims, 19 Drawing Sheets 
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OPERATIONAL SYSTEM FOR OPERATING 
ON CLIENT DEFINED RULES 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is application is a continuation of prior 
application Scr. No. 09/267,589, filed on Mar. 12, 1999 now 
abandoned. 

This is related to U.S. provisional application No. 60/077, 
725 filed on Mar. 12, 1998 and U.S. provisional application 
No. 60/091,270 filed on Jun. 15, 1998, both of which are 
incorporated herein. 

FIELD OF THE INVENTION 

The present invention relates in general to computational 
systems, i.e., computer-based processing systems imple- 
mented in logic including software, hardware and/or firm- 
ware. In particular, the present invention relates to compu- 
tational systems for operating on externally-defined data 
content or data formats (hereinafter "externally-defined 
data"), such as records generated in a business environment, 
based on client-defined rules and metadata. The invention is 
particularly useful in developing and operating computa- 
tional systems that are readily adapted to perform various 
functions in different operating environments, for example, 
billing programs that can be adapted for different business 
environments. 

BACKGROUND OF THE INVENTION 

In many cases, computing systems are required to operate 
on externally-defined data, e.g., business information, mar- 
ket information, scientific data, environmental data or other 
information having a content and/or format determined in 
relation to external or real world events. The computing 
systems perform operations on the externally-defined data 
that are as varied as the data and the environments associated 
with the data. T hese operations may depend, in part, on 
c lient-based rulesTthat is, rules defined by the clien t (e.g., 
party for whom the computing system was developed, or on 
whose behalf the computing system is operated) govern ing 
p rocessing of the data . Accordingly, the computer systems 
and the algorithms implemented by the computer systems 
are typically developed on a case-by-case basis, and are 
limited to the specific application for which they were 
developed. 

In recent years, programmers have devoted considerable 
effort to developing programs that are somewhat adaptable 
to different situations so as to reduce the need to create and 
reprogram source code. Some examples of such adaptable 
programming include configurable systems and object ori- 
ented programming (OOP). Configurable systems typically 
allow the user to select from various options, e.g., a menu of 
options, to customize the system for a given situation. The 
related configuration files may contain, for example, infor- 
mation regarding specific users, specific computers or spe- 
cific programs related to the given situation. OOP generally 
involves programming using objects, i.e., self-contained 
software modules that can be used as independent building 
blocks. Each object includes the commands and data 
required to perform particular functions in response to 
appropriate messages from other objects or systems. 
Generally, new objects of a particular class inherit certain 
characteristics of the existing objects. These objects can be 
re-used or modified to address varying programming situa- 
tions thereby reducing the need, in certain cases, to create 
software routines from scratch. 
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However, the degree of adaptability that is accommodated 
by such programming is generally somewhat limited. Con- 
figurable systems typically support only customization with 
respect to selected option types or from pre-programmed 

5 option fields. Similarly, objects in OOP can be used and 
reused as building blocks but generally only within specific 
operation contexts. As a result, even programmers taking 
advantage of the adaptability afforded by configurable sys- 
tems and OOP are generally limited to writing application - 

10 specific programs. That is, at some point in such programs 
within the binary code, the engines that perform the various 
functions of the program include application-specific ele- 
ments. Accordingly such engines, although perhaps provid- 
ing significant adaptability, are application-specific engines 

35 and would require substantial code revision to be re-used in 
other applications. 

The case of business software and particularly billing 
programs, is illustrative. These programs arc designed to 
provide billing information for particular business environ- 

20 ments where something is rated and billed. However, the 
specific business environments are as varied as the compa- 
nies and industries in which they exist. The differences 
include, for example, industry-related factors and 
organization-related factors. 

25 Among other things, industry-related factors may relate to 
the thing being billed and the format of available business 
records. By way of example, the thing being billed may be 
measured in minutes (e.g., of air time, on-line time, worker 
time spent on a project, etc.), volume or quantity of a 

30 material or commodity (cubic feet of natural gas, or kilowatt 
hours used, number of securities traded, etc.) or in terms of 
monetary units (size of transaction on which commission, 
royalty or service fee is due). The usage or other billing 
information may be provided in an industry standard or 

35 proprietary format, e.g., a call detail record or similar record 
of a telecommunication network. Accordingly, billing pro- 
grams are generally designed on a case-by-case basis to 
handle particular types of data and specific data formats. 

^ Organization -related factors relate to various billing rules 
that are specific to an organization or client. Examples 
include: billing rates that vary depending on time of day or 
day of the week; commission structures that vary depending 
on the type or size of the transaction, volume or commission 

45 sharing rules; company rules governing personal versus 
business expenses; internal bookkeeping rules concerning 
distribution of expenses and receipts as between depart- 
ments or other units of an organization, etc. It is thus 
apparent that billing programs, in addition to addressing data 

5Q types and data formats that vary from industry-to-industry 
(or company-to-company), must also address organization- 
related factors that vary from company-to-company. Similar 
variations are present in a wide-variety of other program- 
ming environments. 

55 In the context of billing programs, companies generally 
use either an off-the-shelf billing program or have a program 
custom developed. Unfortunately, off-the-shelf programs 
generally have a limited ability to address industry-related 
and organization-related variations such as described above. 

60 Some of these available programs include a limited ability to 
customize user interface screens or billing reports, but the 
programs generally support only a small number of pre- 
defined business models corresponding to particular algo- 
rithms that are pre-coded into the programs. 

65 Dissatisfied with the limit a I ions of off-the-shelf programs, 
some companies have had billing programs custom- 
developed for particular applications so as to support 
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externally -defined data according to client-defined rules. For It will be appreciated that the invention encompasses an 
example, a telecommunications company wishing to adaptability that is qualitatively and quantitatively different 
develop a billing program for use in billing its customers, than conventional techniques/systems such as OOP and 
might contract with an outside software developer. The configurable systems. In particular, the computing system of 
developer would spend the time required to understand the 5 the present invention includes functional engines that work 
data content and data format as received by the company. In independent of any application-specific elements, 
the telecommunications industry, such data may be pre- Accordingly, these engines can be transferred from one 
sented in the form of call detail records or similar records application to another without reprogramming any such 
generated by a switch operator on a per call basis including, application dependent elements. Similarly, the application- 
inter alia, time that the call started, time that the call specific modules interact with the functional engines in a 
terminated, the phone number called, and caller's phone manner that is different from conventional messaging- 
number, the MIN/ESN or other information identifying the related interaction. For example, whereas messaging has 
caller to be billed. In addition, the software developer would conventionally been used to effectively call a pre- 
spend time learning the company's billing rules including programmed function of a particular type that may be used 
different rates based on time of the day and day of the week, multiple times in a particular application, or may be used to 
different rates depending on the customer's billing plan, « create new fecords lhat certaifl atlributes of other 
different rates depending on the billing zones (e.g., area records based 0Q the rticulars of an application, the 

codes) of the call and variable rating as a function of call ,. . _ j 1 r *u 

/ „ , « r 1 • • r • t 1 1 application-specific modules of the present mvention mter- 

duration. Based on all of this information, the developer f -a. *u • • ~ *u * a * • u * * 

u.j. j -n act with the engines in a manner that determines what type 

would then design a billing program, and write specific c . , .... t . *f 

& , , , • . , • » 1 ™ of application the engines operate within. That is, the 

algorithms into code that take into consideration the relevant 20 ■ rr ~ r . . 

, 6 - , . t *r i- • application-specific modules tell the engines what kind of 

data, data formats and billing rules. After a preliminary hcitioB t0 ^come. In one case, certain application- 

version of the program is written into code, the code would a _ j 1 ~ *u • * c. «• 

. 1 , , , Sit . specific modules may cause the engines to function as part 

generally be tested, revised, debugged and otherwise run- ♦ ~ / n 1 - • * 1 

Z * 1 • « \ • • * _j 1 of a billing system for a cellular communications network, 

developed, typically during an extensive testmg period, until T «u *u i- .* ^ 1 

. j a- • . CJ - . , r In another case, other application-specific modules may 

the company had sufficient confidence in the program to 25 4l _ . . rr r 4 . , . . 

. .... , 1 t cause the same engines to tunction as a crude oil pricing 

implement it in the company s regular billing system. r r™. 7 e »■ r c *■ i*, i_ 

r . , & J apphcation. This transformation of functionality can be 

The process for developing custom code on a per apph- based on ^ externaU yKlenned data and client-defined 

cation basis is expensive, disruptive to the company's niles 

business, and unreliable. In particular, the developer must T , ... . f 4 . 

. \ e . . . ™ In accordance with one aspect of the present mvention, an 

devote a large amount of time, at the company s expense, to JU ^ * . • •* r r 

, . & , , . . . * . /. apparatus may include: a processing unit for performing 

learning the company s busmess, writing code starting from ♦ *• u j a »• • j . f ■ j 

, & . . , , , , • 1 . ■ . . computation-based functions on generic data units mdepen- 

basic. principles, and developing the code into a functioning , . r t , , , . . 4 . . 4 

, r r ' r b r . b dent of the particular data processing application: an input 

product. Significant company resources are often devoted to - device for recejvi an app i ication _ spe (:iflc inp ut reffiyTlo 

educating the developers, providing test data, analyzing the , c — i — j , v 

r , ,1 . - , ,,1.., the particular data pr ocessing ap phcation; a memory, acces- 

test results and troubleshwtmg the program. In addition due si6Ie""^y~Tne" processing unit, for storing the application 

to the complexity of developmg custom code from basic specific input ; uch thal the processing unh can perform the 

principles, the resulting programs are prone to errors or . t - , , t t . t . • j * •* i_ j 

r , r * - . & A , . .0 computation based functions on the generic data units based 

inadequate performance and may take significant time to tl f .. t . . * . j 

, , . r . - j. n i-ii- on the application-specific input so as to generate computed 

develop into satisfactory products. Because billing programs , . / . * j • • . j «i_ - 

, r , ^.r. ..dn oata; and an output device associated with the processing 

are close to the heart of a company s profitability and its w c m- i- *c * ; u j 

.... ... v . . J . ^ ^ . unit for providing an application-specific output based on 

relationship with its customers, this is a matter of serious , , , , r 

r ■ i 1 , • 1 . the computed data, 

concern to companies. Nonetheless, this development pro- . . . T 

cess has been thought an inherent difficulty of obtaining a ^ P™r<f ! n 8 ™>« «« Incorporated m a network 

computing system having the abUity to fully address the "«« which implement algorithms correspondmg to the 

needs of a specific operating environment and provide the « computation based functions of the generalized platform, 

level of service that some companies or individuals demand. The input device may include a graphical user interface 

d evice fo r accessing a store of data (e.g., a look up table) 

SUMMARY OF THE INVENTION relating extemally- dehned metadata to the generic data units 

It has been recognized that, in a variety of settings, there a nd/or client-defined ruleTfor use by processing a unit . The" 

is a need for reliable and readily developed computing 50 memory mcludes a computer memory configured to store 

systems that support exte rnally-defined data and/or tha t the application-specific input for use by the processing unit, 

support datrEandling according to client-defined rul es. The T° e output device may include one or more of a GUI's or 

present invention is based in part on an understanding that other processing devices which relate the computed data to 

many operating environments involving externally-defined an application -specific output. 

data and/or client-defined rules and metadata can be 55 In another aspect of the invention the system may be 

addressed by computing systems including: 1) a generalized arranged in a multitier structure. A multitier structure may 

functional pl atform having fun ction al elements or "engin es" provide the functionality to perform more application spe- 

that perform f unctions or. given types on generic compu ta- cific processes at the tiers closest to the users, while increas- 

tio^rumts inde pendent of the specific application invo lved. ingly abstract functions are performed at a central location 

in~ooffibinaTion with 2) application-s pecific modules that 60 near the base. Located at the base may be a central server 

receive externally-d efined ^aTa and/or c fientrdeAnSjules. which includes a database. The base server may be con- 

operate^the engines based on these aiwhcation-s riecific nected to at least one application server located at an 

inputs, and output co mputed data having an applicat ion- intermediate tier. The application server may perform func- 

specific content or t drmat . in this manner development time tions relevant to the location it is serving, while the central 

frames are substantially contracted with corresponding cost 65 server may provide services for all parts of the system, 

reductions, and system reliability is greatly enhanced, due to The uppermost tier may include client nodes which act as 

the ability to re -use the generalized platform. the interfaces between the system and the system users. 
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Through the client node, system users may enter applicati on application-specific output includes at least one of a data 
s pecific data, suchas" rules data and definitions, and rece ive content and a data format that is specific to the particular 
outputs related to the processes performed therein. data processing application. For example, the output may 
X As part of the multi-tier system, a data synchronization include billing information expressed in terms appropriate to 
scheme may be employed which includes the functionality 5 the billing application in an organization s billing format. 
. A c - c i • i_ i_ u u u-v. The output may be provided in the form of a transmitted data 
to store subsets of information which have a high probability . . v . t \ , t t t . , . . 
_ . i - . j r. i .j j signal, a printed billing statement or an electronically trans- 
fer use at a tier closer to the client node. Rules are provided _- 4t , . -V t - „ 
,., , . . ... . . , mitted billing statement. 

which are either predetermined or adaptive in nature which A . t . . p « 

f ... , , *; , , j « • According to another aspect of the present invention, a 
identify information which may be of high demand during a method ^ * vided for £ ssi e xleiSally*fined billing 
particular encounter, and back fills this information from the 30 afld custo ^ ef sefvice ^ ated da * fof uge * a ^ 
base tier to the intermediate tier during the encounter. processing platform. The method includes the steps of 
In yet another aspect of the invention, the invention providing a generalized processing platform for performing 
described herein may be implemented as an object oriented billing related functions on generic units, receiving 
system which employs various objects which process data at externally-defined customer usage data relative to a partial - 
different levels of abstraction between the client node and 15 lar billing application, and translating the externally-defined 
the base tier. Presentation objects in the uppermost tier may customer usage data into generic units for use by the 
correspond to one or more business objects that are highly generalized processing platform. The externally-defined 
specific to a client's implementation. These objects may be customer usage data includes an externally-defined data 
focused toward supporting user interfaces, report writers, content (e.g., in units of the thing being billed) and/or an 
etc. Mapping may be provided between the presentation 20 externally-defined data format (an industry standard or pro- 
objects and business objects located on an intermediate tier. P^tary format). The method allows such externally-defined 
The business objects may contain key abstracted business J?^*™ to b fl e ™* b V » generalized processing platform 
logic supported by the particular implementation of the ™ l *£^ y adapted f ° F ° r hmited t0 ^ parUCUlar 
system. Contained within these objects may be the metadata ^ ™ 

and rules necessary to drive the processing engines. 25 DESCRIPTION OF THE DRAWINGS 

Mapping may further be included between the business FIG. 1 is a diagram for the computational architecture, 

objects and domain objects located on the base tier. The FIG. 2 is an embodiment of the computational architec- 

domain objects may correspond closely to a data model ture in a networked system. 

entity or an entity obtained through an external source. The 3Q FIG. 3 is a block diagram disclosing features of adaptive 

domain objects facilitate the location of data required by the tier support. 

presentation and business objects in a database. FIG. 4 is a block diagram which provides an overview of 

In another aspect of the invention, the apparatus performs a object oriented multitier system, 

various billing and customer service related functions. FIG. 5 is a detailed block diagram which shows in 

Under direction from the application specific modules, the 35 particular the configurations of the servers and custom 

functional engines use the customer defined rules to perform interface in a tiered configuration. 

a variety of functions. These function may include a number FIG. 6 is a block diagram describing the operation of the 

of processes related to customer summary information, system manager. 

commitment management, translation, billing and rating, FIG ? ^ a block di describing the operation of the 

recurrent charges, revenue management, output 40 ^es service. 

management, and billing summary. ~ T/ ^ 0 . , , , . . iL 4 . 

& FIG. 8 is a block diagram describing the operation of the 

In another aspect of the mvention, a method is provided eV ent manager 

for enabling a generalized processing platform tobe used for piG. 9 is a block diagram describing the operation of data 

supporting particular processing applications. The method mana g em ent service 

involves providing, as part of a computing program for 45 pjQ 10 * , b i ock diagram 0 f , he computational archi- 

supporting a particular data processing application, a gen- 4 ^ . 4 . ..„. ° ... t F 

i- a 1 *f c c - . *• 1 u a a tecture in the billing system embodiment, 
erahzed platform for performing computational-based func- 

tions on generic data units. The generic data units are FIG - n 18 a s y stem dja 8 ram for the customer summaf y 

expressed in terms independent of the particular data pro- engine. 

cessing application. For example, in the case of a business 50 F . IG - 12 * a s y stem dia g ram for the commitment manager 

application for billing and customer service, the generalized engine. 

platform may include functional components for performing FIG. 13 is a system diagram for the translation engine, 

rating and billing functions. The generic units may be FIG. 14 is a system diagram for the rating engine, 

defined as dimensionless parameters such as rating param- FIG. 15 is a system diagram for the billing engine, 

eters and customer usage parameters, which do not depend 55 FIG. 16 is a system diagram for the recurrent charge 

on the nature of the thing being billed, e.g., whether it is engine. 

defined in a business environment in terms of time, volume, piG. 17 is a system diagram for the revenue management 

kilobytes per second, etc. engine. 

The method further involves receiving an application- FIG. 18 is a system diagram for the output management 

specific input relative to the particular data processing 60 engine. 

application, operating the generalized platform based on the mG 19 fa a systen) diagram for lhe billing summa ry 
application-specific input to generate computed data, and engine, 
providing an application-specific output based on the com- 
puted data. The received application-specific input includes DESCRIPTION OF PREFERRED 
at least one of externally-defined data (e.g., billing records 65 EMBODIMENTS 
provided in an industry standard or company format) and The method and apparatus of the present invention, as 
client-defined rules (e.g., billing rate information). The implemented in connection with the architecture described 
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in detail below, is applicable to a wide variety of applica- facilitates the communication between the processing 

tions for handling externally defined data or for handling engines 12, the rules/metadata engines 14 and other appli- 

data based on client defined rules. Examples of such appli- cations or systems. 

cations include various business, science, process control Disclosed in FIG. 2 is a block diagram of a multi-tiered 

equipment, and engineering applications. In particular, the 5 si tem which incorporates th e computational 

present invention is advantageous in the context of architecture descri5ed above ^ multi . tiered structure pro- 

developing, customizing and operating computing systems t , - . .. t t c ... 

for a number of different applications that share certain Vldes the ********* to perform more application specific 

functional similarity, but differ with respect to specific data F rocesses ?' *? ,lets <; Ioser to ,he »«» of lhe s y stem - and 

types, data formats, organizational details, and other appli- in increasingly abstract functions are performed at a central 

cations for specific matter. 10 locatl0n near the base " 

FIG. 1 illustrates a computational framework or architec- At tbe lowest Uer k a base server 20 which ,s connected 

ture 10 for providing the type of processing described above. lo database of record 22. Within this server are the process- 

This architecture allows certain generic elements or process- in B engines and a portion of the rules/metadata engine 

ing engines to be used to support an environment in which 15 needed 10 perform the processing operations. This server 

a variety of different computations are performed. An impor- ma y be of ,he tv P e currently available, such as a Unix server, 

tant advantage of the illustrated architecture is that virtually which K connectable to a data network and includes data- 

any such business environment can be supported. As a basc search capabilities. The master database is a relational 

result, development risks are minimized and the lime databasc which ma y be used t0 store a number of ^ &KDt 

required to develop and deploy a customized system is 2n types of data ' ^ data ma y generally be characterized as 

reduced. In addition, specific applications can be tailored to metadata, system data and real data. Metadata, as previously 

the needs of a specific company and its industry rather than noted, is the application of mdependent units for internal use 

requiring the company to conform to or settle for an appli- b y ,he processing engines. Real data refers to customer 

cation based on a predefined business model. ^g 6 ^ Md other externally defined or real world data on 

The illustrated architecture may be understood as includ- 25 which calculations may be based. System data encompasses 

ing three components: generic functional elements or aU ° ther data for use by a particular program which 

engines 12, a rules/metadata engine 14, and a messaging includes client defined rules data and translauon definition 

system 16. Information to be processed in the architecture dala -. ^, daUbase ™* be implemented using Oracle 

may be retrieved from data source 18 or other external rela,10nal database software - ^ base j serve r is connected to 

services. Each engine 12 is an autonomous component that 30 at lta f on <; a Pplicat">n serverlocated at a middle tier with 

is focused upon the performance of a well defined function. 10 the o y° ra11 s y s,em - 7,115 connection is established 

Each engine leverages a common framework that facilities via a mcssa 8 e DUS - 

access to resources in common with all the other engines. 0ne of the advantages of the multi-tier system is that the 

While each engine is designed to provide a specific base server may be located in a central location and the 

functionality, its implementation is generic. For example, 35 intermediate servers located remote therefrom. Connection 

one of the engines may be created to perform particular ma y be established through a local area network (LAN) or 

rating processes, like determining a charge for service usage. over me worldwide web. 

In terms of this component, the variable usage represents the At the intermediate tier there is at least one application 
entity being rated and is defined as a unit, where the object server 24 which performs a number of operations 
definition of a unit is provided in a metadata model. For 40 which are relevant to the location which it is serving. The 
example if the unit of measure for specific application is operation of this server will be described in greater detail 
defined to be a megabit per second, the metadata model is below. The application object servers are connected to a 
defined to be a megabit per second, the transferred per database 26 which contains information relevant to perform- 
second. If in another instance, the unit to be measured is ing processing functions at that particular location, 
seconds of air time, the metadata model would simply be 45 The intermediate server may be connected to a data 
altered to redefine the unit of measure as seconds. network, such as a local area network (LAN) through an 

The rules/metadata engine 14 is used to relate the generic Ethernet connection, to a number of graphical user interface 
computational ends to an actual business or scientific func- (GUI) devices 30. GUI's 30 are input/output devices which 
tion. The rules and metadata are two separate tools which allow a system user to enter application-specific data, such 
allow the computational architecture disclosed in FIG. 1 to so as rules, data and definitions, and provide graphical inter- 
be customized for a particular application. The rules provide faces and outputs as desired. The interface may include a 
the guidelines for accessing and storing data, performing keyboard, a mouse, a monitor or similar user interface 
computations within the processing engines, as well as devices. Hie interface may also include input ports for 
providing information to a system user through graphical establishing network connections, with telephony systems, 
user interfaces (GUI's). The employment of rules will be 55 external or external accounting systems, or other sources of 
described in greater detail below. The metadata is used to real data. The output devices may also be included for 
describe the units of data which are processed within the printing customer invoices or the like, 
engines. As was described above, this may be such items as Apparatus may also be pr ovided for electronic tra nsmis- 
units of measure or any other quantity or description which sioDT oTinvoices or billing st atemen ts to multiple custom ers 
a customer would like to measure. These functions may be 60 viajhe world wide web or other public or private network as 
specific to a particular industry, company, division or other max_be_desired. In this regard, the network interface may 
operating unit. The rules/metadata engine also includes a include interface hardware such as dedicated transmission 
number of processing modules for administering the various lines, logic for formatting, data for electronic transmission 
L-functions of the system. and supporting Internet protocol, an encryption or other 

Finally, the messaging system 16 operates under direction 65 security logic for ensuring the privacy of transmitted data, 

of the rules/metadata engines and provides for the routing of Corresponding decryption or other security logic may be 

data signals through the system. The messaging engine 16 resident at the customer nodes 30. 
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In one aspect of the invention, the system may be adapted The master database 40 contains all necessary data which 

to provide customer service functions, where clients or will be retrieved for an encounter with a user. Once an 

customer representatives interact with the system through encounter has been begun, relevant information for that user 

one of a number of intermediate servers 24. As a result of is provided via the communications system to the interme- 

client or customer interaction, the intermediate server gen- 5 diate tier 41 and stored in cached data 44. This information 

erates and captures encounter summary information that is * then accessible at the client node 46. If an encounter is 

communicated to the base server 20. initiated with a user for whom an open commitment exists, 

, data staging services could immediately commence the 

In order to operate in this manner, the data transfer back-filling process for transitioning the appropriate detailed 

between layers must be performed according to a predeter- commitment status data from the base tier to the interme- 

mined scheme. This data synchronization scheme includes 10 diate tier for stor age in the backfilled data 42, based on the 

the functionality to store a subset of information at a tier likelihood that this data will soon be requested at the client 

closer to the system user. The system must also ensure that node 46. 

the information is synchronized horizontally across multiple In order t0 implement a multitiered system as described 

databases. The system supports these requirements and above, and yet provide the necessary performance, an object 

ensures the integrity of the data throughout the system. To ™ or j e nted system is disclosed which employs various objects 

ensure data integrity, all database updates will be made to which pr ocess data at different levels of abstraction between 

the central database of record 22. Data synchronization the client node and the base tier. More specifically, domain, 

involves two types of data: dynamic and semi-static. business, and presentation objects facilitate the abstraction 

Dynamic data refers to data that changes frequently as a of data model relationships from the user interfaces or 

result of input at the client node or business rules. Semi- 20 var j ous engines. 

static data refers to data that seldom changes, and when it Disclosed in FIG. 4 is a high level view of a multitiered 

does it is usually scheduled. object oriented system> is an architecture which divides 

The above is known as an adaptive tier data synchroni- the presentation objects (user interface), business objects, 

zation scheme, and is manifested by two components. The and domain objects into three distinct layers. Each layer or 

first of these is the rule-based message service described uer may reside on a different virtual machine. The presen- 

above. Within any adaptive-tier architecture, business tation object layer 33 provides for communication with the 

objects may reside within any tier, and will require the c ij ent node 31 ^ we ll as with the business object layer, 

ability to communicate with objects resident within any of Interface with the client node 31 is provided through pre- 

the other tiers. Since the routing of messages by the message sentation logic 32. Object mapping 34 is provided between 

service is dictated by an easily configurable ruleset, these the presentation objects 33 and the business objects 35. 

services give the system architect the flexibility to freely The business object layer includes the business objects 35 

map the other components to any of the architectural tiers. and prov ides for communications to the data access layer, or 

In support of any allocation of system components to the domain objects 37. The business objects contain the key 

tiers of an adaptive-tier architecture, inter-components com- ^ abstracted business logic supported by the particular imple- 

munication may be accommodated through simple manipu- mentation of the system. Contained within these objects may 

lation of the message routing rules. b e the metadata and rules necessary to drive the processing 

The second component of the adaptive tier support made engines. Mapping 36 is also provided between the business 

available by the system is a set of data staging services. objects 35 and the domain objects 37. 

These services provide the capability to cache high-interest, 4Q The domain objects 37 correspond closely to a data model 

high-demand data within the intermediate tiers of an entity or an entity obtained through an API from an external 

adaptive-tier architecture. This cached data may be used to source. The domain objects facilitate the location of data 

populate the initial screens required at the client node. In required by the presentation and business objects. Mapping 

addition, the data staging services also provide the capability 3$ jg provided or locating information in the various tables 

to intelligently "back-fill" from the base tier the data 45 39 0 f a relational database. 

required at the client node that was not cached within the Mso included in FIG. 4 is a simplified diagram of the 

intermediate tiers. On behalf of a given user encounter, the mapping which may occur between objects in the system. As 

order in which data is residing within the intermediate tiers mentioned above, the presentation objects control the types 

is targeted by this backfilling process and may be driven by information presented and are specific to a particular client 

such things as the current state of the service provider's 5Q node If for example, a request is made at a client node to 

relationship with that particular customer at the time of the provide current charges for a particular customer, at least 

encounter. The inferential back-filling mechanism is effec- one prestation object 33 is employed to provide this 

lively used to anticipate the encounter-specific requirements information. Mapping may be provided to a number of 

for non-cached data, such that base tier data required to business objects (1-N) 35 in order perform the operations 

support the encounter is actually present within the inter- 55 neC essary to generate the information. Through use of the 

mediate tier by the time that the data is called for at the client mles and me tadata the business objects direct the operation 

noc * e - of the processing engines. 

Rules are provided related to the likelihood that certain \ n ord er to locate the generic units employed by the 

data will be requested during an encounter. The rules processing engines in performing the functions, further ^ ^ 

employed to backfill the data may be based on predeter- 60 mapping i s provided between t he b usiness objects and the 

mined probabilities or may be adaptive in nature. The domain objects. TheHomairi oBjectsTas part of a number of 

operation of the system may be continually monitored and fmicttOTIsf' provide for the location and retrieval of the 

based on past performance, updated probabilities may be necessary generic units from the appropriate tables in the 

generated relating to the type of data which will be used to database. Mapping is provided between the domain objects 

backfill during a particular encounter. 65 to the tables in the database which include the 

Disclosed in FIG. 3 is a diagram which provides an information required by the presentation and business 

illustration of the adaptive tier system for providing data. objects. 
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Disclosed in FIG. 5 is a system diagram for the multit- simply know how to create, read and delete themselves from 

iered system described herein. The diagram has been sim- the data store. The domain objects facilitate the object-to- 

plified for explanation purposes to disclose a single com- relational mapping to the main data store 65. The domain 

munications path between the base tier and a client node. As objects are not expected to change from deployment to 

was disclosed above, a base server may be in connection 5 deployment 

with a number of intermediate servers which ia turn may be , ^^on with the domain object factory, is the main 

in connection with a number of client nodes Eachchent J > 

node includes the f unctionality, as described above, for ... . / - , , t 

dispfeyifiglnd receiving data i nput to the system by sy s tem or an a PP hcat '° n programming interfaces to an external data 

us^TTiTcTfenT^e^ includes a presentation transact ion 1() ""ice. In either case, changes to the database of record, 

controller (PTR)51 and cache 55 which provides for the 10 external data sources or their mterfaces, are confined to the 

4 , , r * , „ j r, lV _ i- „ object server and abstracted from the rest of the system 

temporary local storage of data received from the applica- J . . . , 4l _ \ , 

tion server 52. The FIR 51 is a specialized object that is components. The master database mcludes the stored 

responsible for managing objects within its context and their £ omam ob J ects whlch are access,ble via a relatlonal dala " 

state. In addition, the PTR facilitates the treatment of a base ' 

collection of objects. These objects, as a collection, may be In connection with the object server, or contained within, 

used to satisfy some business logic. As a collection, changes is the engine/application service 62 which includes a portion 

to the objects may be committed as a group or reverted as a of tnc computational architecture described above. Within 

group. The functions performed by the transaction controller the service, the processing engines perform the individual 

include instantiation of the controller, object management, functions employing the objects (which include rules/ 

transaction management and object locking. metadata) received from the business object factory. 

The client node may further include a discretionary access Referring again to the architecture disclosed FIG. 1, the 

control (DAC) device 53. The DAC 53 provides a filter functions performed by the rule/metadata engine 14 with 

(within the translation controller on the registered object to regards to the processing engines are spread across a number 

control their instantiation, deletion, access, update, and 25 of the tiers disclosed in the system of FIG. 5. Included in the 

behavior. These filters may be imposed through configura- rules/metadata engine are a number of processing modules 

tions based upon the criterion of the user. which direct operations of the system. These modules 

J In connection with the client node is the intermediate include system manager 66, rules service manager 67, event 

application server 52 which includes a presentation object manager 68, and data service 69. These services provide a 

factory 57. The presentation object factory 57 provides the 30 common framework for building applications as well as 

application programing interface (API) for application spe- providing methods for the applications to interact and to 

cific objects types. This factory contains knowledge which communicate status to a central location. Each of these 

provides the capability to instantiate specific types of modules will be discussed in detail below, 

objects. A presentation object corresponds to one or more A system diagram showing lines of communication to and 

business objects that are highly specific to a client's imple- 35 from the system manager 66 is shown in detail in FIG. 6. The 

mentation. These objects are focused toward supporting user system manager 66 is a specialized application within the 

interfaces, report writers, etc. The business logic utilizing architecture which provides administrative control to other 

the presentation objects is maintained within the supporting applications. The applications represent any of the engines 

business objects. These objects may change from deploy- in the engine unit which receive and transmit signals to the 

ment to deployment. In connection with the presentation 40 system manager 66, or other processing modules in the 

object factory is the object mapping module 59 which rules/metadata engine. Memory 100 contains a list of reg- 

provides mapping for the presentation objects to business istered engines maintained by the system manager. The 

and domain objects in the object server 56. As with the client system manager updates this collection based on user 

node, the application server 52 includes presentation trans- change requests. The system manager directs other system 

action controller, DAC and data cache. 45 modules, and is responsible for starting and stopping appli- 

A line of communication is established between the cations. Although many of the applications may be devel- 

application server 52 and the object server 56 through the °ped to run continuously, the system manager must initially 

message bus 61. Included in the object server, is the business start lnese applications or may need to restart them if an 

object factory 58. The business object factory may provide anomaly occurs. The system manager may also stop an 

the API necessary to create business objects. The object 50 application in situations such as when an application 

factory knows how to perform these operations using a upgrade is required, 

collection of the domain objects as a basis. The mapping Finally, the system manager monitors an application 
between domain objects and business objects is maintained through a keep-alive mechanism via the messaging service 
within the data model. These mappings include both 86, which means that an application, through its normal 
attributes and relationships. Having these mappings defined 55 communication of events, informs the system manager of its 
within the database, facilitates the ability to configure the operational state. If the application is quiet for a specified 
system from deployment to deployment. These objects amount of time, the system manager performs a poll of the 
inherently derive their behavior from its data and supporting application requiring a response. If the application does not 
data services. Similar to the domain objects, the business respond, the system manager may stop the application and 
objects are not expected to change from deployment to 60 restarts it. All of these functions may be monitored or 
deployment. The business object factory 58 also includes manually controlled through the GUI. 
presentation transaction controller, DAC and data cache. The rules service 67 disclosed in FIG. 7 provides a 
Via the message bus 63, the business object factory is in mechanism for centralized management of system behavior, 
connection with the domain object factory 60. The domain specific application behavior, data interpretation, data rout- 
object corresponds closely to a data model entity or an entity 65 ing between applications, as well as for providing rules to 
obtained through an API from an external source. Domain the overall system. In addition, the rules manager functions 
objects do not necessarily have any business behavior. They as a gateway to assist the engines in their evaluation of the 
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rule. The rules service stores a list of registered rules. These 
rules form the initial list of rules maintained by the rules 
service 101. The rules service updates this collection based 
on user change requests and provides this information to the 
various applications which employ the rules. The rules are 5 
delivered to the various application through message service 
86. 

The messaging service 86 which has been referred to in 
FIGS. 6-9 provides the mechanism for transporting message 
objects between applications. These objects have attributes 1Q 
such as age, priority, transport type (e.g., publish/subscribe, 
peer to peer), transport protocol, and transport security based 
on object type. These attributes allow routing to be estab- 
lished based on these attributes. The actual number of 
applications varies but the interaction of additional applica- 
tions is the same as those represented herein. An application 35 
may also have multiple connections through the messaging 
service. Also there may be multiple message object services 
to help load balancing. In this manner, an application may be 
connected to multiple message services or a message type 
may traverse several message services before being deliv- 20 
ered. 

Disclosed in FIG. 8 is a system diagram for event man- 
ager 68. The event manager 68 provides the mechanism for 
managing complex events across the entire system. These 
events generally require state retention and may be com- 25 
bined with events from other system components. In 
addition, the highly time sensitive events and events that 
may be executed periodically outside of a specific event, are 
managed within this service. The event manager is a rules 
engine designed to be configured for specific complex or 30 
time critical events. Contained in storage 102 are the list of 
events maintained by the event manager. The event manager 
updates this collection based on user change requests. The 
system user may, through a client node, add, delete, modify 
or display particular events. The event manager coordinates 35 
the occurrence of events to the various applications through 
message service 86. 

Disclosed in FIG. 9 is a system diagram showing the lines 
of communication to and from the data management service 
69. The data management service provides the mechanism 40 
for converting between non-object data to an object which 
one of the applications may use. These non-objects may be 
a disk file, a database relation, or other messages. In these 
situations, the service provides the mechanism to open, read 
from, and close the connection. The data management 45 
service 69 provides access to files on disk file storage 116, 
or the retrieval of other information from database 118. 
Further, object mapping data can be retrieved from other 
data sources which are represented by database 120. 

In one embodiment of the invention, the architecture and 50 
related functionality described herein encompass a process 
and system for developing bill and customer service related 
applications; a process and system for managing a billing 
operation; a process system for adapting functional bill and 
customer service related modules from one billing environ- 55 
ment to another; a process and system for extracting infor- 
mation from an externally defined data model for processing 
by generic functional billing module; a process and system 
for operating a billing program according to company- 
specified rules; a process and system for providing a billing 60 
output in terms of specified billing parameters based on 
processing by generic functional billing and customer ser- 
vice modules; a process and system for accessing and 
providing information as part of a customer service function, 
and related software and other logic. 55 

For this embodiment, the architecture described above is 
a system for developing, customizing and operating a num- 
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ber of billing programs for supporting varied billing envi- 
ronments. Such billing programs share certain functional 
similarities. For example, billing programs may involve 
determining a quantitative aspect of customer usage (e.g., a 
telephone call duration), determining a qualitative aspect of 
customer usage (e.g., a rating zone of the calling telephone), 
determining a rate applicable to the customer usage (e.g., 
based on time of call, calling plan) and determining a cost 
associated with the customer usage (e.g., based on duration 
of the call, rating zone, and applicable rate). However, many 
specifics will vary from application to application. For 
example, billing programs may vary due to the nature of the 
externally defined data (e.g., from telephony systems, 
accounting systems) and client based rules (e.g., calling 
plans, security requirements). 

Further, the billing system embodiment is set forth in the 
context of a billing and customer service program with 
particular examples relating to a telecommunications net- 
work. It will be appreciated, however, that various aspects of 
the invention have broader application as noted above, and 
the following description is not intended to limit the scope 
of the appended claims. 

Disclosed in FIG. 10 is an embodiment of the processing 
architecture as it would relate to a billing system. Shown in 
particular are the rules/metadata engine 14 which perform 
various management functions for the billing and customer 
relations system, the processing engines for the billing 
system which include: a customer summary engine 70, a 
commitment management engine 72, a translation engine 
74, a rating engine 76, a billing engine 78, a recurrent 
charges engine 80, a revenue management engine 82, an 
output management engine 84, and a billing summary 
engine 85, as well as messaging 16 for communications 
between the processing engines, the rules/metadata engine, 
and the various data sources which include a legacy system 
91, a billing and customer care data source 93, a data 
warehouse 95, and the various stored rules and metadata 97. 
The operations of these modules in the billing system will be 
described in greater detail below. 

FIGS. 11-18 relate to the operation of the various pro- 
cessing engines in the billing system computational archi- 
tecture. The engines are a number of object oriented soft- 
ware modules that perform billing and customer service 
related functions by operating on generic units independent 
of the specific environment. That is, the internal operation of 
the engines does not depend on the nature of the thing being 
rated or billed, or the customer service provided. The 
engines are based on the concept that many billing and 
customer service related functions can be executed using a 
generic data model supported by rules based logic. In this 
regard, any billing and customer service related functions 
that can be executed using a generic data model may be 
implemented as a engine. It will therefore be appreciated 
that the number and functionality of the engines can be 
varied. The specific engines described below are therefore 
included by way of example only. 

Disclosed in FIG. 11 is a system diagram for the customer 
summary engine 70 showing, in particular, the various lines 
of communications to other components in the system. This 
customer summary engine provides the functionality for a 
customer service representative to quickly ascertain the 
nature of a customer's relationship with the service provider 
when in communication with that customer. This customer 
information may include names and addresses of people 
associated with the account, the customer's hardware 
configuration, the method of payment for the account, and a 
history of the customer's previous contacts with the service 
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provider. Further information may be included about the 
type of relationship established between the service provider 
and the customer. All of this information is stored in an 
external database accessible via data services 90. This 
engine provides the functionality to ensure that the customer 5 
service representative's desk top displays all required infor- 
mation about a specific customer at the time a communica- 
tion is established. The instructions for providing customer 
summary information and for transmitting the information 
once it has been received is done through the messaging 10 
services. 

Included in the engine are a number of generic processing 
modules which perform primary functions. The engine 
executive 92 fields incoming messages from the message 
services 86 and oversees the flow of control signals through ^5 
the functional components which comprise the engine. The 
engine executive will invoke the post process post -encounter 
summary function 96 to assess the impact that a recent 
customer encounter may have had on the customer summary 
information maintained by the system on behalf that cus- 2 o 
tomer. If any impact is identified, the generate customer 
survey function 98 will regenerate the appropriate sections 
of the customer summary information. In addition, if it is 
determined that the relationship attributes for the associated 
customer will potentially be affected by the encounter, the 2 s 
quantify relationship attributes function 94 will be invoked 
to make the necessary calculations. Lastly, the engine execu- 
tive will employ the assessed commitment impact function 
99 to determine if any outstanding commitments have been 
affected by customer encounter, and issue a notification to 30 
the commitment manager accordingly. 

The commitment management engine 72 disclosed in 
FIG. 12 is designed to support the multitude of commitments 
that can be generated from the different customer interfaces. 
Commitments can include customer requests for 35 
information, problem tickets that require resolution, new or 
upgrade orders, system activations, and scheduling for sys- 
tem installations. The commitment is manifested as a 
request, a promise or a transaction, a request represents a 
statement of a commitment goal (such as the repair of a 40 
customer's equipment). A set of promises associated with 
that request represents those tasks that must be completed 
before the request can be declared complete. In response to 
the various actions taken on behalf of commitments in the 
system the commitment manager will provide the following: 45 
centralized control over the execution of requests and their 
associated promises, tracking of these commitments through 
their respective transitional states, a notification to other 
components of the system when any commitment is ful- 
filled. 50 

Returning again to FIG. 12, connections are established 
between the message services 86 and the data service go 
from the various modules within the commitment manager. 
The commitment manager executive 100 fields incoming 
requests from message services and oversees the flow of 55 
control through the functional components comprising the 
commitment manager engine. For those messages related to 
a commitment the commitment manager engine executive 
will invoke the process commitment function to obtain the 
indicated commitment information from data services and 60 
then change the processing stipulated by the message, (e.g., 
check the status of the commitment, or trigger a state 
transition from the commitment). The issue commitment 
notifications module 104 is responsible for initiating any 
coordination with other system components as a result of 65 
change in the commitment status. Functionality is also 
included in the commitment manager to create new com- 
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mitments 108 and manage existing commitments 106. 
Lastly, the coordinate legacy systems function 102 is respon- 
sible for managing any interaction with the legacy commit- 
ment management systems that may be required to support 
the reporting of status on a particular commitment. 

A system diagram for the translation engine 74 is dis- 
closed in FIG. 13. The translation engine is designed to 
convert complex data formats from outside sources, for 
example, EFT or credit card information, into standard 
formats to be used by the system described herein. 
Conversely, the translation engine can format internal sys- 
tem data to be sent to external sources 120. This translation 
function is performed by a suite of tools including a variety 
of conversion routines. The conversion routines are used in 
combination to translate data strings in an input or an output 
mode. For example, an external data format based on an 
industry protocol can be translated into a simplified data 
format for processing by other engines, or output data from 
engines can be converted into an external data format based 
on an industry protocol or billing parameters determined by 
an operating company. 

This particular engine includes formatter routines, for- 
matting rules and processing system services. The transla- 
tion performed by this engine is closely tied with the rules. 
Configuration rules 118 can be applied through the data 
service 86 to initiate the translation engine that will have the 
sole task of formatting data going to and from a specific 
external data source. In these instances a translation engine 
becomes a data gateway for a single external data source. 
One translation engine may perform multiple tasks or indi- 
vidual engines can be applied for specific translation tasks 
which maximize the performance of each functional area in 
the system. 

Referring again to FIG. 13, the translation engine 74 
includes a virtual translation processing module 110 com- 
prised of objects which provide for the creation of an engine 
intent on a specific purpose, such as an external data 
gateway. The configuration model 112 includes functionality 
for setting up the differences in the translation engine 
instances. For example, data pattern rules for format trans- 
lation and functional rules may be used to govern the engine 
behavior in the system. The two format modules 116 and 114 
are overloaded functions set by the data pattern rules from 
the configuration module 172. In each engine, there will be 
a format module to format data from the external data source 
to the system format, and a format module to translate data 
from the system format to an external data format. Both of 
these modules may use the same rules to format data, the 
main difference being that each format module will work on 
its own thread and will essentially be a one way gate for 
data. 

The rating engine 76 disclosed in FIG. 1 4 is designed for 
the real time c omputation ol 1charg e^data^as s75c1aleo^with a 
p articular service ev ent. The engine also associates that 
charge with a particular customer. The service evenfrepre- 
sents a si"ngle~instance~of ^service usage and may be a 
temporarily bounded event such^55^cohnection, a one time 
service such as installation, or a product purchase. The rating 
engine communicates with the rest of the system through the 
messaging services 86. Infor mation related to customers, 
pric es, and geogr aphic informati on isslofled Ifl the databas e 
124. This system further"inclucles a method of matching* 
events to customers and billing plans based on a select 
criteria. Rate plans are applied to a unit of measure and may 
be varied depending on parameters which may include: day 
of the week, time of day, arbitrarily-defined geographic 
zones where the event originated and terminated, distance 
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span, event duration, terminating device type, carrier, and module 208 may be logically combined to form more 

direction of data transfer. complex discounting schemes, and may be applied to indi- 

Returning again to FIG. 14, the system manager 80 vidual charges or groups of charges. The separation module 

through message handler 122 provides a centralized initia- 202 aUows f * u , b . scnb « s t0 te g rou P ed t0 8 elher J ?» the 

lion and termination of the system processes. The messaging 5 Purposes of billing The groups are then arranged into an 

service provides for bi-directional message flow between the ilbllt ^ More »P^ticated rule base separation 

r , . . j may then be supenmposed on this hierarchy. Different 

system manager and the ratmg processes The initialized ^ / afation mles £ iy be applied to different components of 

rating function 126 is responsible for initializing the rating ch Separation rules may be logically combined 

state machines and service event queues. Once preliminary (0 fonn more lex ^^0,, ^ for example , he 

iniuation tasks are performed, an engine registration request 10 wm ^ ^ ^ m 

is sent to the system manager. When a termination message A j- r *• u v j * *• u 

. , J . & . + t . . . x. A rounding function may be applied at any time, such as 

is received, an engine registration request is sent to the a & 4 . J .11.. 

, a f ter discounting, separation, tax calculations or current 

sys em manager. conversions. Rounding is applied according to a set of rules 

The retrieve rating objects 130 has three primary func- and they include the foUowing types: round up, round down, 

tions. The first is executing queries against a persistent store. and round t0 the nearest ^ invoice generation module 212 

Second is a relation-to-object data mapping. The third is an generates an invoice after all discounting and separation has 

object assembly and disassembly. The engine cache manager been performed and any appropriate taxes added. All line 

134 is responsible for managing cache rating objects. It items for each mvoice are then tagged ^ invoice number 

provides mechanisms for storage, retrieval, and manage- and passe(i on to outpul manageme nt 84. In the situations 

ment of objects date changes. The process service record where ^ency conversion is necessary, this information is 

function 128 is responsible for monitoring inbound service provided from currency conversion module 200. 

event queue. Hie rate record function 132 performs the ^ fecurrent ^ me 80 disdosed m nQ w 

process which is responsible tor establishing single or hafldles ^ geQeration of charfies that 

recur on a regular 

multiple threads of execution for the remainder of the ratmg basig such as monlnI seryice cfa ^ ch 
process, ^number of threads needed to handle service e ^ forms {oQ of and terminating 
event record demand can be changed dynamically. eilher Qr according t0 a set of flexible mles 
The examine service event characteristics module 136 xh e event manager manages the scheduling of charge gen- 
provides a number of different functionalities. They include eration. Once signaled by the event manager, the recurrent 
determining service type, record validation services, service 3Q charges engine loads the necessary customer information, 
event record to addressable unit mapping services, addres- b iu mg cyc i e information, and package price information, 
sable unit to rate plan services, normalization of daytimes, tben begins generating the line item charges for each cus- 
determination of service event origination and tomer. As each charge is generated the recurrent charge 
determination, and determination of service provider. The engine schedules the next generation of the charge based 
apply applicable rating rule module 138 is essential for the 3S upon tDe cyc i e for that charge. 

rating calculator. This process takes as input all applicable Referring again to FIG. 16, through the data services 90 
rating rules to determine and examine characteristics and the recU rrent charge engine has access to items such as the 
apply the resulting charge to the service event record. billablc items queuCj the mlc ^ ^ system information . 
Finally, the process outbound record module 140 is respon- within the recurrent charges engine is a generate charge 
sible for- processing outbound service records. It provides 4Q f^ion 220. The recurrent charges engine relies on an 
mechanisms for handling the routing of rated service events, external signal from the event manager t0 initiate charge 
service record exception handling, and rejected service computations. The recurrent charge engine loads necessary 
events. customer information, billing information, and package 
The billing engine 78 disclosed in FIG. 15 rates service price information. Then it begins generating the line item 
use at an aggregated level. It may be used to rate summary 45 charges. As each charge is generated the recurrent charge 
usage records or apply to a collection of service usage engine schedules the next occurrence of the charge genera- 
records. The managed billing features may include volume tion. The proration function 222 may be applied in either a 
discount schedules, tiered costs based on transaction standard or non-standard manner as defined by the rules and 
aggregation, special promotions, ability to identify and this proration function is supplied to the identified charges, 
apply separation of charges between groups and individual 50 Also based on the rules, a rounding function 224 may round 
user's companies, and ability to pay applied taxes. In order the charges up, down or to the nearest whole number as 
to retrieve information for these different functions a number designated. 

of different databases are connected to the billing system. Disclosed in FIG. 17 is a revenue management engine 82. 

One database may include system information 186, another The revenue management engine provides business func- 

may include external data gateway information 198, and a 55 tionality including remittance management, revenue 

third may include a billable items queue 196. The billing recognition, earned and unearned income management, and 

module also accesses a set of rules and invoices through delinquency in connection with distribution of revenue. The 

other databases. revenue management engine interfaces with the message 

Referring again to FIG. 15, the collection of customer service to exchange account information with various finan- 

charges module 204 gathers customer charges for the billing 60 cial gateways and sends deactivation and activation requests 

engine to apply to proration module 206. Prior to the billing to the addressability gateway. In addition it may receive 

process, the engine begins by reading through all charges of remittance requests from a remittance gateway. The revenue 

an indicated billing cycle and grouping them by customer management system also interacts with the primary data 

and charge type. Once the charges have been collected, the store through the data services to retrieve billing information 

discounting module 208 applies a discount both before and 65 and persistent account information, and with the data stored 

after separation. Discounting is applied according to a series distribution rules prioritization of applied payment rules, 

of rules provided by the rule set 192. Discounting rules account transition rules, and adjustment rules. 
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Referring again to FIG. 17, the delinquency and collec- 
tions module 234 manages account and aging rules. Outputs 
can be generated for referrals to collection agencies. The 
account management module 232 matches payments to 
outstanding balances and open items. It identifies the rev- 
enue account to which to apply the remittance and allocates 
it accordingly. Revenue recognition module appropriately 
applies prepaid funds to the proper revenue account. It also 
correctly recognizes and manages earned and unearned 
income. Finally, the charge processing module 236 ensures 
that revenue based on a single transaction may be distributed 
multiple merchants. 

Disclosed in FIG. 18 is a system diagram for the output 
management engine 84. Incorporating rules from the rules 
engine, via the messaging service, reports can be generated 
in response to requests from a number of different sources, 
a CSR or customer may directly through a data network 
initiate a command to the output management engine, to 
issue a single report 240 on a particular customer. A system 
user through the GUI may request a batch report 244 which 
are then output, via the data service, in a desired format. 
Finally the system administrator may also create, modify, 
and delete reports 246 which are stored in the database. 

The billing summary engine 85 disclosed in FIG. 19, is 
responsible for gathering the customer data produced by 
billing and revenue management and presenting it in a form 
that can be transformed into a customer invoice. Billing 
summary engine reads and sorts all account data, generates 
all the information needed for the invoice, and produces an 
output data file according to format specifications stored in 
one of the databases. The resulting output data file may then 
be forwarded to an appropriate agent for printing and 
mailing. 

Referring again to FIG. 19, connections are established 
via the message services as well as the data services to 
various system databases. The read invoice data module 250 
reads in all billing information for each account for the 
specified billing cycle. This includes account charges, 
credits, adjustments, and totals as well as the billing address 
for the account. The sort and order module 252 finds out 
which report is the invoice for each account, and loads the 
charge type mapping for that report. This charge type 
mapping is then used to order all the account charges for 
each invoice. The add/remit/return addresses module 254 
locates the remit and return addresses for each invoice. The 
add notices module 256 places special notices on the invoice 
or includes it with the invoice. Finally, the format invoice 
data module 258 puts the invoice in the proper format for 
printing. 

The foregoing description of the present invention has 
been presented for purposes of illustration and description. 
Furthermore, the description is not intended to limit the 
invention to the form disclosed herein. Consequently, varia- 
tions and modifications commensurate with the above 
teachings, and the skill or knowledge of the relevant are, 
within the scope of the present invention. The embodiments 
described hereinabove are further intended to explain best 
modes known for practicing the invention and to enable 
others skilled in the art to utilize the invention in such, or 
other, embodiments and with various modifications required 
by the particular applications or uses of the present inven- 
tion. It is intended that the appended claims be construed to 
include alternative embodiments to the extent permitted by 
the prior art. 

What is claimed is: 

1. An apparatus comprising: 

a central server located at a base tier to provide services 
for the system; 
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a database located at the base tier connected to the central 
server, 

at least one application server to perform functions rel- 
evant to the location it is serving, the application server 
5 being located at an intermediate tier connected to the 
central server; 

client nodes through that system users may enter appli- 
cation specific data, such as rules data and definitions, 
and receive outputs related to the processes performed 
10 therein, the client nodes being located at an uppermost 
tier and connected to the at least one application server; 

a data synchronization scheme that includes functionality 
to store subsets of information that have a high prob- 
ability for use by a client node; and 

rules that identify the subsets of information for a par- 
ticular user encounter, the rules adaptive in nature such 
that the operation of the system is continually moni- 
tored and, based on past performance, updated prob- 
20 abilities are generated relating to the type of data that 
will be used to backfill during a particular encounter. 

2. The apparatus of claim 1, wherein the subsets of 
information are stored at the intermediate tier. 

3. The apparatus of claim 1, wherein the rules are prede- 
25 termined, 

4. The apparatus of claim 1, wherein the data synchroni- 
zation scheme caches data from the base tier to the inter- 
mediate tier to populate initial screens required at the client 
nodes during a user encounter. 

30 5. The apparatus of claim 4, wherein the data synchroni- 
zation scheme back-fills from the base tier data required at 
a client node during a user encounter that was not cached 
within the intermediate tiers. 

6. The apparatus of claim 5, wherein the back-filled data 
35 is ordered to anticipate a user's requirements for non-cached 

data at the time of the user encounter. 

7. The apparatus of claim 1, wherein the data synchroni- 
zation scheme back-fills the subsets of information from the 
base tier to the intermediate tier during a user encounter. 

4Q 8. The apparatus of claim 7, wherein the backfilled data is 
ordered by the current state of the apparatus relationship 
with that particular user at the particular client node at the 
time of the user encounter. 

9. The apparatus of claim 1, wherein the data synchroni- 
45 zation scheme stores subsets of information within the 

intermediate tier by the time that the subsets of information 
is called for at a particular client node. 

10. The apparatus of claim 1, wherein if an encounter is 
initiated with a user for whom an open commitment exists, 

5Q the data synchronization scheme stores appropriate detailed 
commitment status data from the base tier to the interme- 
diate tier based on a likelihood that this data will soon be 
requested at the client node. 

11. A system comprising: 

55 a central server that includes a data storage device, and a 
business object generator that generates business 
objects that contain abstracted business logic; 
a computational platform in connection with the central 
server that performs compulation-based functions 

60 under the direction of rules and metadata used by the 
business objects; 
at least one intermediate server in connection with the 
base server via a message bus where the intermediate 
server includes a presentation object generator to gen- 

65 erate presentation objects based on the business 
objects, the presentation objects being specific to a 
particular user of the system; 
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at least one user interface that receives and displays 
presentation objects, and provides requests to the inter- 
mediate server to retrieve information and to have 
processes performed at the base server; and 

a data cache associated with the intermediate server to 
store presentation objects to be sent to the at least one 
user interface in advance of a request from the user 
interface, the data cache to populate initial screens 
requested by the user interface. 

12. The system of claim 11 wherein Ihe data in the data 
cache is inferentially back-filled to anticipate requests from 
the user interface by the time that the data is requested from 
the user interface. 

13. The system of claim 11 wherein the operation of the 
system is continually monitored and based on past 
performance, updated probabilities are generated relating to 
the type of data which will be stored in the data cache during 
a particular user encounter. 

14. The system of claim 11, wherein the data storage 
device includes a relational database. 

15. The system of claim 14, wherein the intermediate 
server provides object- to-relational mapping for the presen- 
tation objects to the business objects in the base server. 

16. The system of claim 11, wherein the intermediate 
server and the user interface are connected via a data 
network. 

17. The system of claim 16, wherein the data network is 
the world wide web. 

18. The system of claim 16, wherein the data network is 
a local area network. 

19. The system of claim 11, wherein the intermediate 
server is located remote from the base server and the 
message bus is provided via a communications network. 

20. An apparatus for processing information according to 
a particular application, comprising: 

a computational platform for performing computation- 
based functions on generic data units independent of 
the particular application; 

an interface that provides for receipt and transmission of 
data related to the particular application, and provides 
rules and metadata to the computational platform to 
convert the generic data units to units associated with 
the particular application; 

an output device for providing an application specific 
output based on the data units, the application specific 
output including one of a data content and a data format 
that is specific to the particular application; 

a messaging service that provides for transport of infor- 
mation between the computational platform, the 
memory, and the output device; and 

a data staging service that caches high interest data for the 
output device, the data staging service to use cached 
data to populate initial screens requested by a client 
node. 

21. The apparatus of claim 20, wherein the computational 
platform includes at least one processing engine that per- 
forms computation based functions free from elements spe- 
cific to the particular data processing application, the at least 
one processing engine comprising at least one of: 

a customer summary engine that accesses and provides 
customer summary information through the output 
device; 

a translation engine that provides for conversion of data 
formats received and transmitted from the computa- 
tional platform; 

a rating engine that provides for computation of charges 
related to a service event; 
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a billing engine that rates services provided at an aggre- 
gate level; 

a user interface engine that controls information move- 
ment to and from the interface; and 
5 an output engine that provides for outputting of reports. 

22. The apparatus of claim 20, further comprising a 
central server associated with the computational platform 
and at least one intermediate server located between the 
central server and the output device, wherein the data 

10 staging service, based on information received from the 
output device, retrieves information from the central server 
and stores the information in a local memory. 

23. The apparatus of claim 22, wherein a connection is 
established between the local memory and the output device 

15 over a local area network. 

24. The apparatus of claim 22, wherein a connection is 
established between the local memory and the output device 
over the world wide web. 

25. The apparatus of claim 20, wherein the data staging 
20 service provides the capability to intelligently back-fill data 

requested at a client node from the computational platform. 

26. The apparatus of claim 25, wherein the intelligent 
back-fill capability is driven by the current state of a service 
provider's relationship with a particular customer at the time 

25 of an encounter. 

27. The apparatus of claim 25, wherein the intelligent 
back-fill capability is used to anticipate client node requests 
for non-cached data. 

28. The apparatus of claim 25, wherein the intelligent 
30 back-fill capability is adaptive in nature so that the operation 

of the system is monitored and based on past performance, 
updated probabilities are generated relating to the type of 
data which will be used to backfill. 

29. A method comprising; 

35 containing data which will be retrieved for an encounter 
with a user in a master database; 
providing relevant information for the user to an inter- 
mediate tier from the master database; 
4Q storing the relevant information in a data cache; 

making the relevant information accessible to the user at 

a client node; and 
backfilling further relevant information in the data cache 
to anticipate user requests for non-cached data, the 
45 backfilling adaptive in nature so that the operation at 
the client node is monitored and, based on past 
performance, updated probabilities are generated relat- 
ing to the type of data which will be used to backfill. 

30. The method of claim 29, further comprising back- 
50 filling to transition appropriate detailed commitment status 

data from the master database to the data cache, if an 
encounter is initiated with a user for whom an open com- 
mitment exist. 

31. The method of claim 29, further comprising populat- 
55 ing initial screens required by the client nodes during an 

encounter with the user. 

32. The method of claim 29, further comprising if an open 
commitment exists for the user, storing appropriate detailed 
commitment status data from the base tier to the interme- 

60 diate tier. 

33. An apparatus comprising: 

a central server located at a base tier to provide services 
for the system; 

a database located at the base tier connected to the central 
65 server; 

at least one application server to perform functions rel- 
evant to the location it is serving, the application server 
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being located at an intermediate tier connected to the 
central server; 

client nodes through that system users may enter appli- 
cation specific data, such as rules data and definitions, 
and receive outputs related to the processes performed 5 
therein, the client nodes being located at an uppermost 
tier and connected to the at least one application server; 
and 

a data synchronization scheme that includes functionality 
to store subsets of information that have a high prob- 10 
ability for use by a client node, the data synchronization 
scheme to cache data from the base tier to the inter- 
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mediate tier to populate initial screens required at the 
client nodes during a user encounter. 

34. The apparatus of claim 33, wherein the data synchro- 
nization scheme back-fills from the base tier data required at 
a client node during a user encounter that was not cached 
within the intermediate tiers. 

35. The apparatus of claim 34, wherein the back-filled 
data is ordered to anticipate a user's requirements for 
non-cached data at the time of the user encounter. 

* * * * * 
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